In a presence network, such as the presence service proposed by the Open Mobile Alliance (OMA) standards or a Parlay X-based network, a presence entity, such as a Presentity in an OMA-based system, is a logical entity associated with a Presence User (for example, representing a human or a communication device) that has presence information associated with it. A Presence Source associated with the presence entity provides presence information about the presence entity to a Presence Server, and a Watcher requests presence information about the presence entity from the Presence Server. For example, in an OMA-based system, a Presence Source, implemented in a communication device operated by a first Presence User, may publish presence information to the Presence Server by conveying a Session Initiation Protocol SIP (Session Initiation Protocol) PUBLISH message comprising the presence information to the Presence Server. The presence information includes a current state of user status attributes associated with the presence entity, such as Presence Information Elements in an OMA-based system, for example, a location, an availability, a willingness, a mood, an activity, and so on. The Presence Server then stores the current state of the user status attributes in association with the presence entity. In addition, the Presence Server maintains a profile in association with each presence entity, which profile may include access rules that determine which set of Watchers are authorized to see presence information associated with the presence entity.
A second Presence User may wish to know a state of presence information associated with the first Presence User. In order to be informed of the presence information, a Watcher implemented in a second communication device associated with the second Presence User creates a subscription at the Presence Server to watch the first Presence User and/or to watch a group of Presence Users (also called a ‘Resource List’). For example, in an OMA-based system, the Watcher may request to watch by conveying a SIP SUBSCRIBE message to the Presence Server requesting presence information associated with the watched entity (that is, the first User) or group of watched entities (that is, the group of Presences Users). Each subscription has an expiry value associated with it, which expiry value can be requested by a Watcher but overridden by the Presence Server. Prior to the expiration of the expiry value, the Watcher needs to refresh the subscription in order to prevent the subscription from lapsing.
In subscribing to watch a presence entity/group of watched entities, the Watcher may request notification concerning all user status attributes associated with each such presence entity, or may request notification concerning only select user status attributes. If the Watcher is authorized by the Presence Server, for example, by the access rules associated with a presence entity, the Watcher is then provided with a current state of each requested user status attribute, for example, via a SIP NOTIFY message in an OMA-based system.
A Presence Source associated with a presence entity then publishes a presence information update to the Presence Server every time a state of one or more user status attributes changes, regardless of the user status attributes watched by the Watcher/second Presence User. When the Presence Server receives the presence information update, the Presence Server forwards the update to the Watchers that have subscribed to that user status attribute of that presence entity.
Scenarios exist where some subscriptions hosted by a Presence Server need to be terminated, at least temporarily. Once such subscriptions are terminated, clients, for example, Watchers, will keep retrying to re-subscribe at pre-determined intervals or will stop trying altogether. The repeated attempts at re-subscription causes subscription requests to hit the Presence Server periodically, which the Presence Server may continue to reject, resulting in a waste of server resources. Further, the repeated attempts at re-subscription consume user terminal battery life and, where a number of terminated subscriptions is high, could congest a system.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will further be appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. Those skilled in the art will further recognize that references to specific implementation embodiments such as “circuitry” may equally be accomplished via replacement with software instruction executions either on general purpose computing apparatus (e.g., CPU) or specialized processing apparatus (e.g., DSP). It will also be understood that the terms and expressions used herein have the ordinary technical meaning as is accorded to such terms and expressions by persons skilled in the technical field as set forth above except where different specific meanings have otherwise been set forth herein.